This option causes a subsequent connect syscall to only bind the
remote address, leaving the TCP connection initiation for a later
data-send call. This supports applications where the transport
connect coding is a long way away from the data-send (eg. the
latter is in a TLS library) and the wish is for data-bearing
TCP Fast Open.

The option name matches that used by the Linux kernel.

For discussion:

• The implementation also does the equivalent of a TCP_FASTOPEN
  setsockopt; is this wanted or should they be separated?
  It does not support the PSK mode of TCP_FASTOPEN; is that wanted?
• The implementation diverges the "connected" socket state from
  the actual state of the TCP connection; is this acceptable
  architecturally?
• Testing: only kernel bootabilty and feature-exercise testing has
  been done. Is there a networking testsuite?